GraphQL是facebook在2015年推出的一種新型態的API，那為甚麼要使用這種api呢? RESTful API不好嗎?

• RESTful的確有一些優點，例如容易撰寫，方便直接，但它的缺點也顯而易見，假如今天我們要抓使用者資料，但我們 可能只需要用到其中的幾個欄位，RESTful卻會把所有的欄位都抓回來。
  並且普遍的流程是前端等後端開好api，再去做串接。但GraphQL採取一種比較直覺的方式來讓抓取資料，並且可以根據需求，彈性的選擇自己所要的欄位。再前端方面，無疑是一種福音(會有種再前端下SQL語法的感覺)

• 此外，RESTful以資料節點的方式來表現資料，允許你可以透過GraphQL語法，來獲取不同資料原的資料。在gatsby中，能讓你方便的以GraphQL來獲取目錄資訊、本地目錄檔案、以及抓取資料庫，並能藉由使用各種外掛套件與各種CMS進行串接，做到完全的內容與網頁做分離。

• 無關GraphQL的題外話，今天看文檔教學時，在gatsby中，它甚至允許你用抓來的資料，搭配自己需要的組件，生成靜態的頁面，大幅降低在頁面切換時的時間花費(不需要一值抓資料)，以別人的說法來講:使用者體驗極佳。

• 簡單總結，GraphQL可以視為一種新的趨勢，以前端來說更直覺，並且在抓取大量資料時，有更好的效能，且可以以相當結構化的方式來得到自己的資料。

接下來的這個小節和React一樣以基本的功能和介紹為主，因為我們後面會用到的語法並沒有特別多，如果要求詳細介紹，一樣是文檔的教學最完整。

舉個最簡單的例子來作為開始好了

user
---
id:1, name:'Jack'
id:2, name:'Bob'
---

假如我們用GraphQL要取抓取這張表的資料，那我們下的query可能就會長得像這樣:

{
  allUsers {
    id
    name
  }
}

這個query可能是我們對一個GraphQL API server做請求時，所傳的字串，現在慣例上似乎都是用POST以query這個參數名來傳遞給server。

當server接受到以後它會經由resolver來進行解析，決定要做甚麼事和回傳甚麼資料。

而以上例來講，它可能就會返回一個json，長得像這樣:

{
  allUsers: [
    {
      id: 1,
      name: "Jack"
    },
    {
      id:2,
      name: "Bob"
    }
  ]
}

參考連結:

• GraphQL文檔 (官方文檔，但以語法介紹為主，因為我們有太多的方法去實作GraphQL，包括許多不同的語言以及不同的第三方套件，因此文檔中不教如何實作。)

• How To GraphQL (實作為主的教學，下方提供了許多的語言和環境的組合，手把手的教導怎麼使用，但並非所有語言都有。rails的api我就是參考這個文檔做出來的。)

未來這些天的規劃

系列文未來的走向是，系望能用三種方式去介紹如何以GraphQL去串接資料

• 檔案目錄中，以markdown的方式存放資料 (有興趣請見Gatsby官方文檔，有剖詳細的教學)
• 第三方後端開的GraphQL API (以rails實作出來的，但不會詳細實作的過程，畢竟不是我們的主題，又要提到rails就講不完了) (僅示範如何使用，最後實作使用CMS)
• CMS中來管理的資料 (目前計畫是使用wordpress) (以Contentful實作)

一開始參加時沒想到這麼有趣，雖然平常沒有寫文章的習慣，但透過這次的鐵人賽，確實讓我花了更多的時間去熟悉文檔，30天內要把幾個完全不會的技術摸到能夠使用並做出一個小東西，似乎也並沒有想像中的困難。
雖然不是撰寫自己最熟悉的東西，但的確對我的幫助是很大的。